The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Importantly, although the operational/functional descriptions described herein are understandable by the human mind, they are not abstract ideas of the operations/functions divorced from computational implementation of those operations/functions. Rather, the operations/functions represent a specification for the massively complex computational machines or other means. As discussed in detail below, the operational/functional language must be read in its proper technological context, i.e., as concrete specifications for physical implementations.
The logical operations/functions described herein are a distillation of machine specifications or other physical mechanisms specified by the operations/functions such that the otherwise inscrutable machine specifications may be comprehensible to the human mind. The distillation also allows one of skill in the art to adapt the operational/functional description of the technology across many different specific vendors' hardware configurations or platforms, without being limited to specific vendors' hardware configurations or platforms.
Some of the present technical description (e.g., detailed description, drawings, claims, etc.) may be set forth in terms of logical operations/functions. As described in more detail in the following paragraphs, these logical operations/functions are not representations of abstract ideas, but rather representative of static or sequenced specifications of various hardware elements. Differently stated, unless context dictates otherwise, the logical operations/functions will be understood by those of skill in the art to be representative of static or sequenced specifications of various hardware elements. This is true because tools available to one of skill in the art to implement technical disclosures set forth in operational/functional formats—tools in the form of a high-level programming language (e.g., C, java, visual basic, etc.), or tools in the form of Very high speed Hardware Description Language (“VHDL,” which is a language that uses text to describe logic circuits)—are generators of static or sequenced specifications of various hardware configurations. This fact is sometimes obscured by the broad term “software,” but, as shown by the following explanation, those skilled in the art understand that what is termed “software” is a shorthand for a massively complex interchaining/specification of ordered-matter elements. The term “ordered-matter elements” may refer to physical components of computation, such as assemblies of electronic logic gates, molecular computing logic constituents, quantum computing mechanisms, etc.
The last two decades have seen a vast increase in implementation of electronic systems in vehicles. These systems are configured to control and/or monitor almost every aspect of vehicle operations. Possible applications range from engine operations, driving assistance modules, steering control, door opening and locking, speed sensors, light control, safety mechanisms (e.g. ABS brakes, air bags and etc.), and others as known in the art. The communication means and software protocols connecting between a vehicle's electronic systems (electronic control units) and sensors is known as CAN (controller area network) bus. CAN regulate the way in which the data is transferred between different ECUs and allows cars to optimize performance, act on emergency, and become economical and safer.
Currently, there are no efficient, cost effective and simple means to stop anyone with malicious intent and some computer programming skills from taking command of a vehicle via its electronic systems and portions. Following access, a person with a malicious intent could control any vehicle feature. Although current vehicle communication systems are configured to cope with various technical difficulties, they are mostly unsecure against malicious attacks. Further, connecting external communication systems to the vehicle, such as mobile communication, and multimedia networks increase the susceptibility of the vehicle systems to attacks from the outside. A person with malicious intent can interfere with the CAN communication and transmit faulty communication frames or faulty error frames in attempt to change the reaction of at least one ECU. Another vulnerability in entailed in the fact that almost all possible bus messages, their respective structures and communication protocols are specified in publically available documents.
The CAN protocol is based on the principle of broadcast transmission. Generally, data is sent to all the nodes in the network, including to the destination node. Typically, an ECU connected to a CAN constantly monitors traffic for data indented for them to process while discording the rest.
Some of the important CAN features include speed, data length and being an event trigger mechanism. The event trigger mechanism means that the transmission of data is prompt only when a specific event occurs. For example pressing a button or a pedal will cause a transfer of data. CAN utilizes an addressing system based on identifiers rather than physical addresses for each node. In addition each identifier assigns a priority to the respective message based on binary value. If a node in a CAN detects an error, it will immediately abort the transmission and broadcast an error frame consisting of an error flag made up of a bit string that violates the bit stuffing rule, all other nodes will respond by transmitting error flags too. Following a sufficient number of error flags, a node will eventually turn itself off.
Another important use of affecting CAN communication is the possibility to override technical problems by manipulating CAN traffic.
Prior art article “CAN ERROR INJECTION, A SIMPLE BUT VERSATILE APPROACH”, H. Webermann, A. Block, 2012, esd, electronic system design, pg. 14-19, discloses a CAN system bus implemented with an error injector. The Error injector is configured to insert various errors, when triggered, into the bus communication. Working in parallel to the normal function of the CAN controller, the invention uses the errors as means to control the distribution of the frames. A detected error will cause the frame to be destroyed, using the principle that dominant bits cannot be overridden by recessive bits. The error injector is implemented as a bit stream injector, which can be triggered by several trigger modules.
Another example of bus security solutions is WO 2013/144962 A1 titled: “SECURITY SYSTEM AND PROTECTING A VEHICLE ELECTRONIC SYSTEM”. This innovation discloses a security system for a vehicle electronic system by selectively intervening in the communications path in order to prevent the arrival of malicious messages at ECUs, in particular at the safety critical ECUs. The security system includes a filter which prevents illegal messages sent by any system or device communicating over a vehicle communications bus from reaching their destination, and the option of setting a rating of suspicious messages transferred through. Further the system discloses the filtering of a message according to message ID, message data field, message length, and according to the port the message was received.
However, all of the above examples utilize means and methods aiming at cancelling and/or filtering malicious messages requiring a lot of time and/or effort, and may require initial knowledge about the network architecture, number of ECUs, proprietary commands and so on. In addition, there are currently no means of addressing any malicious or faulty communication that has succeeded in passing through to at least one ECU.
There is a long felt need for means and methods that can divert the effect a malicious communication has on an existing ECU by manipulating the ECU response to these communications.
As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. “such as”) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.